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Abstract 


This document defines a convergence layer for Content-Centric Networking (CCNx) and Named 
Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks 
(LOWPANSs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU 
size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats 
are described. To support compatibility with other LOWPAN technologies that may coexist on a 
wireless medium, the dispatching scheme provided by IPv6 over LOWPAN (6LOWPAN) is extended 
to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of 
the 6LOWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In 
its second part, the document defines stateless and stateful compression schemes to improve 
efficiency on constrained links. Stateless compression reduces TLV expressions to static header 
fields for common use cases. Stateful compression schemes elide states local to the LOWPAN and 
replace names in Data packets by short local identifiers. 


This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 
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This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet- 
related research and development activities. These results might not be suitable for deployment. 
This RFC represents the consensus of the Information-Centric Networking Research Group of the 
Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9139. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


The Internet of Things (IoT) has been identified as a promising deployment area for Information- 
Centric Networking (ICN), as infrastructureless access to content, resilient forwarding, and in- 
network data replication demonstrates notable advantages over the Internet host-to-host 
approach [NDN-EXP1] [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate 
mapping to link-layer technologies has a large impact on the practical performance of an ICN. 
This will be even more relevant in the context of IoT communication where nodes often 
exchange messages via low-power wireless links under lossy conditions. In this memo, we 
address the base adaptation of data chunks to such link layers for the ICN flavors NDN [NDN] and 
CCNx [RFC8569] [RFC8609]. 


The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and lossy networks (see LLN in 
[RFC7228]), in which devices are typically battery operated and constrained in resources. 
Characteristics of LLNs include an unreliable environment, low-bandwidth transmissions, and 
increased latencies. IEEE 802.15.4 admits a maximum physical-layer packet size of 127 bytes. The 
maximum frame header size is 25 bytes, which leaves 102 bytes for the payload. IEEE 802.15.4 
security features further reduce this payload length by up to 21 bytes, yielding a net of 81 bytes for 
CCNx or NDN packet headers, signatures, and content. 
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6LOWPAN [RFC4944] [RFC6282] is a convergence layer that provides frame formats, header 
compression, and adaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 
6LOWPAN adaptation introduces a dispatching framework that prepends further information to 
6LOWPAN packets, including a protocol identifier for payload and meta information about 
fragmentation. 


Prevalent packet formats based on Type-Length-Value (TLV), such as in CCNx and NDN, are 
designed to be generic and extensible. This leads to header verbosity, which is inappropriate in 
constrained environments of IEEE 802.15.4 links. This document presents ICN LOWPAN, a 
convergence layer for IEEE 802.15.4 motivated by 6LOWPAN. ICN LoWPAN compresses packet 
headers of CCNx, as well as NDN, and allows for an increased effective payload size per packet. 
Additionally, reusing the dispatching framework defined by 6LOWPAN enables compatibility 
between coexisting wireless deployments of competing network technologies. This also allows 
reuse of the adaptation-layer fragmentation scheme specified by 6LOWPAN for ICN LoWPAN. 


ICN LOWPAN defines a more space-efficient representation of CCNx and NDN packet formats. This 
syntactic change is described for CCNx and NDN separately, as the header formats and TLV 
encodings differ notably. For further reductions, default header values suitable for constrained 
IoT networks are selected in order to elide corresponding TLVs. Experimental evaluations of the 
ICN LOWPAN header compression schemes in [ICNLOWPAN] illustrate a reduced message 
overhead, a shortened message airtime, and an overall decline in power consumption for typical 
Class 2 devices [RFC7228] compared to uncompressed ICN messages. 


In a typical IoT scenario (see Figure 1), embedded devices are interconnected via a quasi- 
stationary infrastructure using a border router (BR) that connects the constrained LOWPAN 
network by some gateway with the public Internet. In ICN-based IoT networks, nonlocal Interest 
and Data messages transparently travel through the BR up and down between a gateway and the 
embedded devices situated in the constrained LOWPAN. 


|Gateway Services| 


| | 
| BR | 
| | 
LoOWPAN 
(0) (o) 
(ol 
0) (0) embedded 
(0) (0) (0) devices 
(0) (0) 


Figure 1: IoT Stub Network 
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The document has received fruitful reviews by members of the ICN community and the research 
group (see the Acknowledgments section) for a period of two years. It is the consensus of ICNRG 
that this document should be published in the IRTF Stream of the RFC series. This document does 
not constitute an IETF standard. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


This document uses the terminology of [RFC7476], [RFC7927], and [RFC7945] for ICN entities. 


The following terms are used in the document and defined as follows: 


ICN LOWPAN: Information-Centric Networking over Low-Power Wireless Personal Area 


Network 
LLN: Low-Power and Lossy Network 
CCNx: Content-Centric Networking 
NDN: Named Data Networking 
byte: synonym for octet 
nibble: synonym for 4 bits 


time-value: atime offset measured in seconds 


time-code: an 8-bit encoded time-value 


3. Overview of ICN LOoWPAN 


3.1. Link-Layer Convergence 


ICN LoWPAN provides a convergence layer that maps ICN packets onto constrained link-layer 
technologies. This includes features such as link-layer fragmentation, protocol separation on the 
link-layer level, and link-layer address mappings. The stack traversal is visualized in Figure 2. 
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Device 1 Device 2 
sain as sc aa a as ; Router pe Soe Renae P 
[ee AID Le Cacao pcre T | ,-> Application | 
| Reece a lial l NDN / CCNx l [eare aa a 
| NDN / CCNx lea | Giese sss>>s >>> ma Ld NDN / CCNx | 
po R eee ee eeac I [el orate eon | 
| ICN LoWPAN I | | ICN LoWPAN | | | | ICN LoWPAN | 
eee ee ss lola essen es Bi ee ae | 
| Link Layer laa | | Link Layer | | hed Link Layer | 


Figure 2: ICN LOWPAN Convergence Layer for IEEE 802.15.4 


Section 4 of this document defines the convergence layer for IEEE 802.15.4. 


3.2. Stateless Header Compression 


ICN LoWPAN also defines a stateless header compression scheme with the main purpose of 
reducing header overhead of ICN packets. This is of particular importance for link layers with 
small MTUs. The stateless compression does not require preconfiguration of a global state. 


The CCNx and NDN header formats are composed of Type-Length-Value (TLV) fields to encode 
header data. The advantage of the TLV format is its support of variably structured data. The main 
disadvantage of the TLV format is the verbosity that results from storing the type and length of 
the encoded data. 


The stateless header compression scheme makes use of compact bit fields to indicate the 
presence of optional TLVs in the uncompressed packet. The order of set bits in the bit fields 
corresponds to the order of each TLV in the packet. Further compression is achieved by specifying 
default values and reducing the range of certain header fields. 


Figure 3 demonstrates the stateless header compression idea. In this example, the first type of the 
first TLV is removed and the corresponding bit in the bit field is set. The second TLV represents a 
fixed-length TLV (e.g., the Nonce TLV in NDN), so that the Type and Length fields are removed. The 
third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which the Type, 
Length, and Value fields are elided. 
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Uncompressed: 

Variable-length TLV Fixed-length TLV Boolean TLV 
oan mee +------- +------- ie ete +------- +------- TE +------ A 
i TYP 1 LEN J] VAL |] TYP | LEN J] VAL | TYP | LEN ] 
+------- +------- +------- +------- +------- +------- +------ +------ + 
Compressed: 


+---+---+---+---+---+---+---+---+} 
oija olola i Bit Field 
+---+---+---+---+---+}---+---+---+} 


1 1 1 


ioc ----, - Boolean Value 


Var-len Value Fixed-len Value 
Figure 3: Compression Using a Compact Bit Field -- Bits Encode the Inclusion of TLVs 


Stateless TLV compression for NDN is defined in Section 5. Section 6 defines the stateless TLV 
compression for CCNx. 


The extensibility of this compression is described in Section 4.1.1 and allows future documents to 
update the compression rules outlined in this document. 


3.3. Stateful Header Compression 


ICN LoWPAN further employs two orthogonal, stateful compression schemes for packet size 
reductions, which are defined in Section 8. These mechanisms rely on shared contexts that are 
either distributed and maintained in the entire LOWPAN or are generated on demand hop-wise on 
a particular Interest-Data path. 


The shared context identification is defined in Section 8.1. The hop-wise name compression "en 
route" is specified in Section 8.2. 


4. IEEE 802.15.4 Adaptation 


4.1. LoWPAN Encapsulation 


The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes 
problems of misinterpreting frames when several network layers coexist on the same link. To 
mitigate errors, 6LOWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames 
(see Section 5 of [RFC4944]). Multiple LOWPAN encapsulation headers can precede the actual 
payload, and each encapsulation header is identified by a dispatch type. 
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[RFC8025] further specifies dispatch Pages to switch between different contexts. When a LOWPAN 
parser encounters a Page switch LOWPAN encapsulation header, all following encapsulation 
headers are interpreted by using a dispatch Page, as specified by the Page switch header. Pages 0 
and 1 are reserved for 6LOWPAN. This document uses Page 14(1111 1110 (@xFE)) for ICN 
LoWPAN. 


The base dispatch format (Figure 4) is used and extended by CCNx and NDN in Sections 5 and 6. 


7) 1 2 3 
+---+---+---+---+--- 


ae A e] 
+---+---+---+---+--- 


Figure 4: Base Dispatch Format for ICN LOWPAN 


P: Protocol 
0: Theincluded protocolis NDN. 


1: The included protocolis CCNx. 


M: Message Type 
0: The payload contains an Interest message. 


1: The payload contains a Data message. 


C: Compression 
0: The message is uncompressed. 


1: The message is compressed. 


ICN LOWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch 
format in Figure 5. 


7) 1 2 3 Ton 
+---+---+---+---+...+---+---+ 
LATE ua | CID| EXT | 
+---+---+---+---+...+---+---+ 


Figure 5: Extended Dispatch Format for Compressed ICN LOWPAN 


CID: Context Identifier 
0: No context identifiers are present. 


1: Context identifier(s) are present (see Section 8.1). 


EXT: Extension 
0: No extension bytes are present. 


1: Extension byte(s) are present (see Section 4.1.1). 
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The encapsulation format for ICN LoWPAN is displayed in Figure 6. 


+------ e +------ a +-------- +------- Te +----- ae 
| IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 
+------...------ +------ .----- +-------- +------- ...------- +----- TO 


Figure 6: LOWPAN Encapsulation with ICN LOWPAN 


IEEE 802.15.4: The IEEE 802.15.4 header. 

RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 of [RFC4944]. 
Page: Page switch. 14 for ICN LOWPAN. 

ICN LOWPAN: Dispatches as defined in Sections 5 and 6. 


Payload: The actual (un-)compressed CCNx or NDN message. 


4.1.1. Dispatch Extensions 


Extension bytes allow for the extensibility of the initial compression rule set. The base format for 
an extension byte is depicted in Figure 7. 


7) 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
E a l EXT 
+---+---+---+---+---+---+---+---+ 
Figure 7: Base Format for Dispatch Extensions 


EXT: Extension 
0: No other extension byte follows. 


1: A further extension byte follows. 


Extension bytes are numbered according to their order. Future documents MUST follow the 
naming scheme EXT_@, EXT_1, ... when updating or referring to a specific dispatch extension 
byte. Amendments that require an exchange of configurational parameters between devices 
SHOULD use manifests to encode structured data in a well-defined format, e.g., as outlined in 
[ICNRG-FLIC]. 


4.2. Adaptation-Layer Fragmentation 


Small payload sizes in the LOWPAN require fragmentation for various network layers. Therefore, 
Section 5.3 of [RFC4944] defines a protocol-independent fragmentation dispatch type, a 
fragmentation header for the first fragment, and a separate fragmentation header for 
subsequent fragments. ICN LOWPAN adopts this fragmentation handling of [RFC4944]. 


Gündoğan, et al. Experimental Page 10 


RFC 9139 ICN Adaptation to LOWPANs November 2021 


The fragmentation LOWPAN header can encapsulate other dispatch headers. The order of 
dispatch types is defined in Section 5 of [RFC4944]. Figure 8 shows the fragmentation scheme. The 
reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in 
Figure 9. 


+------ ...------ +----...---- +-------- +------ ...------- +-------- 

| IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 
+------ I R a I a a a laa 
+------ ...------ +----...----+-------- ; 

| IEEE 802.15.4 | Frag. 2nd | Payload / 

+------...------ +----...----+-------- 

+------ ...------ +----...----+-------- E 

| IEEE 802.15.4 Frag. Nth | Payload / 


| 
+------ agg ee Ga ge EE 
Figure 8: Fragmentation Scheme 


+------ P +-------- +------ ra +-------- T 
| IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 
+------...------ +-------- +------ ...------- +-------- ae 


Figure 9: Reassembled ICN LOWPAN Frame 


The 6LOWPAN Fragment Forwarding (6LFF) [RFC8930] is an alternative approach that enables 
forwarding of fragments without reassembling packets on every intermediate hop. By reusing the 
6LOWPAN dispatching framework, 6LFF integrates into ICN LOWPAN as seamlessly as the 
conventional hop-wise fragmentation. However, experimental evaluations [SFR-ICNLOWPAN] 
suggest that a more-refined integration can increase the cache utilization of forwarders ona 
request path. 


5. Space-Efficient Message Encoding for NDN 


5.1. TLV Encoding 


The NDN packet format consists of TLV fields using the TLV encoding that is described in [NDN- 
PACKET-SPEC]. Type and Length fields are of variable size, where numbers greater than 252 are 
encoded using multiple bytes. 


If the type or length number is less than 253, then that number is encoded into the actual Type or 
Length field. If the number is greater or equals 253 and fits into 2 bytes, then the Type or Length 
field is set to 253 and the number is encoded in the next following 2 bytes in network byte order, 
i.e., from the most significant byte (MSB) to the least significant byte (LSB). If the number is 
greater than 2 bytes and fits into 4 bytes, then the Type or Length field is set to 254 and the 
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number is encoded in the subsequent 4 bytes in network byte order. For larger numbers, the Type 
or Length field is set to 255 and the number is encoded in the subsequent 8 bytes in network byte 
order. 


In this specification, compressed NDN TLVs encode Type and Length fields using self-delimiting 
numeric values (SDNVs) [RFC6256] commonly known from Delay-Tolerant Networking (DTN) 
protocols. Instead of using the first byte as a marker for the number of following bytes, SDNVs use 
a single bit to indicate subsequent bytes. 


Value NDN TLV Encoding SDNV Encoding 

0 0x00 0x00 

127 Ox7F Ox7F 

128 0x80 0x81 0x00 

253 OxFD 0x00 OxFD 0x81 0x7D 

214.1 OxFD Ox3F OxFF OxFF 0x7F 

214 OxFD 0x40 0x00 0x81 0x80 0x00 

216 OxFE 0x00 0x01 0x00 0x00 0x84 0x80 0x00 

921_4 OxFE 0x00 0x1F OxFF OxFF OxXFF OxFF 0x7F 

921 OxFE 0x00 0x20 0x00 0x00 0x81 0x80 0x80 0x00 
928_4 OxFE OxOF OxFF OxFF OxFF OxFF OxFF OxFF 0x7F 

228 OxFE 0x1F 0x00 0x00 0x00 0x81 0x80 0x80 0x80 0x00 
232 OxFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x90 0x80 0x80 0x80 0x00 


2354 OxFF 0x00 0x00 0x00 0x07 OXFF OxXFF OXFF OxFF OxFF OxFF OxFF OxFF 0x7F 


235 OxFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x81 0x80 0x80 0x80 0x80 0x00 
Table 1: NDN TLV Encoding Compared to SDNVs 


Table 1 compares the required bytes for encoding a few selected values using the NDN TLV 
encoding and SDNVs. For values up to 127, both methods require a single byte. Values in the range 
(128...252) encode as one byte for the NDN TLV scheme, while SDNVs require two bytes. Starting at 
value 253, SDNVs require a less or equal amount of bytes compared to the NDN TLV encoding. 
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5.2. Name TLV Compression 


This Name TLV compression encodes Length fields of two consecutive NameComponent TLVs 
into one byte, using a nibble for each. The most significant nibble indicates the length of an 
immediately following NameComponent TLV. The least significant nibble denotes the length of a 
subsequent NameComponent TLV. A length of 0 marks the end of the compressed Name TLV. The 
last Length field of an encoded NameComponent is either 0x00 for a name with an even number 
of components and OxYF (Y > 0) ifan odd number of components are present. This process limits 
the length of a NameComponent TLV to 15 bytes but allows for an unlimited number of 
components. An example for this encoding is presented in Figure 10. 


Name: /HAW/Room/481/Humid/99 


o 1 2 3 
A Sh ey Cah A a S A ash S oh T te} 2) (2) A r te toy T e S ) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|8 @11]8 1 8 @ H l A l W 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| R | o | o | m | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
KEE E E E 4h 4 l 8 l 1 l 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| H | u | m | i | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l d |8 © 1808|00 @ Ø| 9 l 9 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 10: Name TLV Compression for /HAW/Room/481/Humid/99 


5.3. Interest Messages 


5.3.1. Uncompressed Interest Messages 


An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C, P, 
and M flags to @ (Figure 11). The Interest message is handed to the NDN stack without 
modifications. 


Q 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
PA e a Ves aa oe a eae | 
+---+---+---+---+---+---+---+---+ 


Figure 11: Dispatch Format for Uncompressed NDN Interest Messages 
5.3.2. Compressed Interest Messages 


The compressed Interest message uses the extended dispatch format (Figure 5) and sets the C flag 
to 1 andthe P and M flags to 9. If an Interest message contains TLVs that are not mentioned in 
the following compression rules, then this message MUST be sent uncompressed. 
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This specification assumes that a HopLimit TLV is part of the original Interest message. If such a 
HopLimit TLV is not present, it will be inserted with a default value of DEFAULT_NDN_HOPLIMIT 
prior to the compression. 


In the default use case, the Interest message is compressed with the following minimal rule set: 


1. The Type field of the outermost MessageType TLV is removed. 


2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are 
expected to be of type GenericNameComponent with a length greater than 0. An 
ImplicitSha256DigestComponent or ParametersSha256DigestComponent MAY appear at the 
end of the name. In any other case, the message MUST be sent uncompressed. 


3. The Nonce TLV and InterestLifetime TLV are moved to the end of the compressed Interest, as 
illustrated in Figure 12. The InterestLifetime is encoded as described in Section 7. On 
decompression, this encoding may yield an InterestLifetime that is smaller than the original 
value. 


4. The Type and Length fields of Nonce TLV, HopLimit TLV, and InterestLifetime TLV are elided. 
The Nonce value has a length of 4 bytes, and the HopLimit value has a length of 1 byte. The 
compressed InterestLifetime (Section 7) has a length of 1 byte. The presence of a Nonce TLV 
and InterestLifetime TLV is deduced from the remaining length to parse. Aremaining length 
of 1 indicates the presence of an InterestLifetime, a length of 4 indicates the presence of a 
nonce, and a length of 5 indicates the presence of both TLVs. 


The compressed NDN LoWPAN Interest message is visualized in Figure 12. 


T = Type, L = Length, V = Value 
Lc = Compressed Length, Vc = Compressed Value 


: = optional field, | = mandatory field 
+--------- +--------- + +--------- + 
| Msg T | Msg L | | Msg Le | 
+--------- +--------- +--------- + +--------- + 
| Name T | Name L | Name V | | Name Vc | 
+--------- +--------- +--------- + +--------- +--------- + 
: CBPFx T : CBP tice L : : FWDH Le : FWDH Vc 
+--------- +--------- + +--------- +--------- + 
MBFr T MBFr L [HRI Vi | 
+--------- +--------- +--------- + ==> +--------- +--------- + 
FWDH T FWDH L FWDH VaT: APM Lc APM Vc 
+--------- +--------- +--------- + +--------- +--------- + 
NONCE T NONCE L NONCE V : NONCE V 
+--------- +--------- +--------- + +--------- + 
EI 1 ILT L TA V LEG vic 
+--------- +--------- +--------- + +--------- + 
HPL T HPL L HPL V 
+--------- +--------- +--------- + 
APM T APM L APM V 
+--------- +--------- +--------- + 


Figure 12: Compression of NDN LOWPAN Interest Message 


Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 13. 
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8) 1 

Geel aa a AS a 7y G o o l 2 gJ Aa g 
+---+---+---+---+---+---+---+}---+---+---+---+---+---+---+---+---+ 
| @ | Ə | @ | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT| 
+---+---+---+---+---+---+---+}---+---+---+---+---+---+---+---+---+ 


Figure 13: Dispatch Format for Compressed NDN Interest Messages 


PFX: CanBePrefix TLV 
0: The uncompressed message does not include a CanBePrefix TLV. 


1: The uncompressed message does include a CanBePrefix TLV and is removed from the 
compressed message. 


FRE: MustBeFresh TLV 
0: The uncompressed message does not include a MustBeFresh TLV. 


1: The uncompressed message does include a MustBeFresh TLV and is removed from the 
compressed message. 


FWD: ForwardingHint TLV 
0: The uncompressed message does not include a ForwardingHint TLV. 


1: The uncompressed message does include a ForwardingHint TLV. The Type field is 
removed from the compressed message. Further, all link delegation types and link 
preference types are removed. All included names are compressed according to Section 
5.2. If any name is not compressible, the message MUST be sent uncompressed. 


APM: ApplicationParameters TLV 
0: The uncompressed message does not include an ApplicationParameters TLV. 


1: The uncompressed message does include an ApplicationParameters TLV. The Type field is 
removed from the compressed message. 


DIG: ImplicitSha256DigestComponent TLV 
0: The name does not include an ImplicitSha256DigestComponent as the last TLV. 


1: The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and 
Length fields are omitted. 


RSV: Reserved 
Must be set to 0. 


CID: Context Identifier 
See Figure 5. 


EXT: Extension 
0: No extension byte follows. 


1: Extension byte EXT_@ follows immediately. See Section 5.3.3. 
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5.3.3. Dispatch Extension 
The EXT_@ byte follows the description in Section 4.1.1 and is illustrated in Figure 14. 


(2] 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+} 
| NCS | RSV [EXT | 
+---+---+---+---+---+---+---+---+ 


Figure 14: EXT_0 Format 


NCS: Name Compression Strategy 
00: Names are compressed with the default name compression strategy (see Section 5.2). 


01: Reserved. 
10: Reserved. 
11: Reserved. 


RSV: Reserved 
Must be set to 0. 


EXT: Extension 
0: No extension byte follows. 


1: A further extension byte follows immediately. 


5.4. Data Messages 


5.4.1. Uncompressed Data Messages 


An uncompressed Data message uses the base dispatch format and sets the Cand P flags to 8 and 
the M flag to 1 (Figure 15). The Data message is handed to the NDN stack without modifications. 


7) 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
Moneo meoo 
+---+---+---+---+---+---+---+---+ 


Figure 15: Dispatch Format for Uncompressed NDN Data Messages 
5.4.2. Compressed Data Messages 


The compressed Data message uses the extended dispatch format (Figure 5) and sets the C and M 
flags to 1. The P flag is set to 9. If a Data message contains TLVs that are not mentioned in the 
following compression rules, then this message MUST be sent uncompressed. 
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By default, the Data message is compressed with the following base rule set: 


1. The Type field of the outermost MessageType TLV is removed. 

2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are 
expected to be of type GenericNameComponent and to have a length greater than 0. In any 
other case, the message MUST be sent uncompressed. 

3. The MetaInfo TLV Type and Length fields are elided from the compressed Data message. 

4. The FreshnessPeriod TLV MUST be moved to the end of the compressed Data message. Type 
and Length fields are elided, and the value is encoded as described in Section 7 as a 1-byte 
time-code. If the freshness period is not a valid time-value, then the message MUST be sent 
uncompressed in order to preserve the security envelope of the Data message. The presence 
of a FreshnessPeriod TLV is deduced from the remaining one-byte length to parse. 

5. The Type fields of the SignatureInfo TLV, SignatureType TLV, and SignatureValue TLV are 
removed. 


The compressed NDN LOWPAN Data message is visualized in Figure 16. 


T = Type, L = Length, V = Value 
Lc = Compressed Length, Vc = Compressed Value 


: = optional field, | = mandatory field 

+--------- +--------- + +--------- + 

| Msg T | Msg L | | Msg Le | 

+--------- +--------- +--------- + +--------- + 

| Name T | Name L | Name V | | Name Vc | 

+--------- +--------- +--------- + +--------- +--------- + 

: Meta T Meta L Cypr Ec CTyp V 

+--------- +--------- +--------- + +--------- +--------- + 
CTyp T CTyp L Chypy Vv: FBID V 

+--------- +--------- +--------- + ==> +--------- +--------- + 
Foer I Reem (ke ae wy CONT Lc CONT V_: 

+--------- +--------- +--------- + +--------- +--------- + 
FBID T FBID L_ : FBID V I Sie Le] 

+--------- +--------- +--------- + +--------- +--------- + 

CONT E CONT E CONT NV | SInf Le | SInf Vc | 

+--------- +--------- +--------- + +--------- +--------- + 

Sale) | Sige l | SVal Le | SVal Ve | 

+--------- +--------- +--------- + +--------- +--------- + 

(Sacer [| Simne E | S a a (ile Wie 

+--------- +--------- +--------- + +--------- + 

| SVal T | SVal L | SVal V | 

+--------- +--------- +--------- + 


Figure 16: Compression of NDN LOWPAN Data Message 


Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 17. 
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2) 1 

2) 1 2 3 4 5 6 7 8 9 (2) 1 2 3 4 5 
+---+---+---+---+---+}---+---+---+}---+---+---+---+---+---+---+---+ 
| @ | @ | 1 | 1 |FBI|CON|KLO| RSV |CID| EXT | 
+---+---+---+---+---+}---+---+---+}---+---+---+}---+---+---+}---+---+ 


Figure 17: Dispatch Format for Compressed NDN Data Messages 


FBI: FinalBlockId TLV 
0: The uncompressed message does not include a FinalBlockId TLV. 


1: The uncompressed message does include a FinalBlockId, and it is encoded according to 
Section 5.2. If the FinalBlockId TLV is not compressible, then the message MUST be sent 
uncompressed. 


CON: ContentType TLV 
0: The uncompressed message does not include a ContentType TLV. 


1: The uncompressed message does include a ContentType TLV. The Type field is removed 
from the compressed message. 


KLO: KeyLocator TLV 
0: Ifthe included SignatureType requires a KeyLocator TLV, then the KeyLocator represents 
a name and is compressed according to Section 5.2. If the name is not compressible, then 
the message MUST be sent uncompressed. 


1: Ifthe included SignatureType requires a KeyLocator TLV, then the KeyLocator represents 
a KeyDigest. The Type field of this KeyDigest is removed. 


RSV: Reserved 
Must be set to 0. 


CID: Context Identifier 
See Figure 5. 


EXT: Extension 
0: No extension byte follows. 


1: Extension byte EXT_@ follows immediately. See Section 5.4.3. 


5.4.3. Dispatch Extension 
The EXT_@ byte follows the description in Section 4.1.1 and is illustrated in Figure 18. 


(2] 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+} 
| NCS | RSV [EXT | 
+---+---+---+---+---+---+---+---+ 


Figure 18: EXT_0 Format 
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NCS: Name Compression Strategy 
00: Names are compressed with the default name compression strategy (see Section 5.2). 


01: Reserved. 
10: Reserved. 
11: Reserved. 


RSV: Reserved 
Must be set to 0. 


EXT: Extension 
0: No extension byte follows. 


1: Afurther extension byte follows immediately. 


6. Space-Efficient Message Encoding for CCNx 


6.1. TLV Encoding 
The generic CCNx TLV encoding is described in [RFC8609]. Type and Length fields attain the 
common fixed length of 2 bytes. 


The TLV encoding for CCNx LoWPAN is changed to the more space-efficient encoding described in 
Section 5.1. Hence, NDN and CCNx use the same compressed format for writing TLVs. 


6.2. Name TLV Compression 


Name TLVs are compressed using the scheme already defined in Section 5.2 for NDN. If a Name 
TLV contains T_IPID, T_APP or organizational TLVs, then the name remains uncompressed. 


6.3. Interest Messages 


6.3.1. Uncompressed Interest Messages 


An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the Cand 
M flags to @. The P flag is set to 1 (Figure 19). The Interest message is handed to the CCNx stack 
without modifications. 


7) 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
PATEE a E a eS eB es || 
+---+---+---+---+---+---+---+---+ 


Figure 19: Dispatch Format for Uncompressed CCNx Interest Messages 
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6.3.2. Compressed Interest Messages 


The compressed Interest message uses the extended dispatch format (Figure 5) and sets the Cand 
P flags to 1. The M flag is set to @. If an Interest message contains TLVs that are not mentioned in 
the following compression rules, then this message MUST be sent uncompressed. 


In the default use case, the Interest message is compressed with the following minimal rule set: 


1. The version is elided from the fixed header and assumed to be 1. 


2. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the 
fixed header on decompression. 


The compressed CCNx LOWPAN Interest message is visualized in Figure 20. 


T = Type, L = Length, V = Value 
Lc = Compressed Length, Vc = Compressed Value 


= optional field, | = mandatory field 
+----------------------------- + +------------------------- + 
| Uncompr. Fixed Header | | Compr. Fixed Header | 
+----------------------------- + +------------------------- + 
+--------- +--------- +--------- + +--------- + 

ICT T HL ILT y ILT Vc 
+--------- +--------- +--------- + +--------- + 
: MSGH T : MSGH L : MSGH V MSGH Vc 
+--------- +--------- +--------- + +--------- + 
+--------- +--------- + +--------- + 
| MSGT T | MSGT L | | Name Vc | 
+--------- +--------- +--------- + +--------- + 
| Name T | Name L | Name V | ==> : KIDR Vc 
+--------- +--------- +--------- + +--------- + 
: KIDR T : KIDR L : KIDR YV :; : OBHR Vc 
+--------- +--------- +--------- + +--------- +--------- + 

OBHR T OBHR L OBHR V : PAYL Le PAYL V 
+--------- +--------- +--------- + +--------- +--------- + 

PAYL T PAYL L PAYL V : VALG Lc VALG Vc 
+--------- +--------- +--------- + +--------- +--------- + 
> VALGE T : VALGE = VALEV : : VPAY Le VPAY V 
+--------- +--------- +--------- + +--------- +--------- + 
: VPAY T : VPAY LE : VPAYV : 
+--------- +--------- +--------- + 


Figure 20: Compression of CCNx LOWPAN Interest Message 


Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 21. 
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Q 1 

Gail 209 a iG be ee a O i 2 a A G 
+---+---+---+---+---+---+---+}---+---+---+---+---+---+---+---+---+ 
| @ | 1 | @ | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT| 
+---+---+---+---+---+---+---+}---+---+---+---+---+---+---+---+---+ 


Figure 21: Dispatch Format for Compressed CCNx Interest Messages 


FLG: Flags field in the fixed header 
0: The Flags field equals 0 and is removed from the Interest message. 


1: The Flags field appears in the fixed header. 


PTY: PacketType field in the fixed header 
0: The PacketType field is elided and assumed to be PT_INTEREST. 


1: The PacketType field is elided and assumed to be PT_RETURN. 


HPL: HopLimit field in the fixed header 
0: The HopLimit field appears in the fixed header. 


1: The HopLimit field is elided and assumed to be 1. 


FRS: Reserved field in the fixed header 
0: The Reserved field appears in the fixed header. 


1: The Reserved field is elided and assumed to be 9. 


PAY: Optional Payload TLV 
0: The Payload TLV is absent. 


1: The Payload TLV is present, and the Type field is elided. 


ILT: Optional hop-by-hop InterestLifetime TLV 
See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. 


0: No InterestLifetime TLV is present in the Interest message. 


1: An InterestLifetime TLV is present with a fixed length of 1 byte and is encoded as 
described in Section 7. The Type and Length fields are elided. 


MGH: Optional hop-by-hop MessageHash TLV 
See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. 


This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the 
Interest MUST be sent uncompressed. 


0: The MessageHash TLV is absent. 


1: AT_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field 
is assumed to represent 32 bytes. The outer Message Hash TLV is omitted. 
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KIR: Optional KeyIdRestriction TLV 
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the 
Interest MUST be sent uncompressed. 


0: The KeyldRestriction TLV is absent. 


1: AT_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field 
is assumed to represent 32 bytes. The outer KeyIdRestriction TLV is omitted. 


CHR: Optional ContentObjectHashRestriction TLV 
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the 
Interest MUST be sent uncompressed. 


0: The ContentObjectHashRestriction TLV is absent. 


1: AT_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field 
is assumed to represent 32 bytes. The outer ContentObjectHashRestriction TLV is omitted. 


VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 
0: No validation-related TLVs are present in the Interest message. 


1: Validation-related TLVs are present in the Interest message. An additional byte follows 
immediately that handles validation-related TLV compressions and is described in 
Section 6.3.2.2. 


CID: Context Identifier 
See Figure 5. 


EXT: Extension 
0: No extension byte follows. 


1: Extension byte EXT_®@ follows immediately. See Section 6.3.3. 


6.3.2.1. Hop-By-Hop Header TLVs Compression 


Hop-by-hop header TLVs are unordered. For an Interest message, two optional hop-by-hop header 
TLVs are defined in [RFC8609], but several more can be defined in higher-level specifications. For 
the compression specified in the previous section, the hop-by-hop TLVs are ordered as follows: 


1. InterestLifetime TLV 
2. Message Hash TLV 


Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain 
uncompressed in the encoded message, and they appear after the InterestLifetime and 
MessageHash TLVs in the same order as in the original message. 


6.3.2.2. Validation 
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2) 1 2 3 4 5 6 7 8 
+------- +------- +------- +------- +------- +------- +------- +------- + 
| ValidationAlg | KeyID | RSV | 
+------- +------- +------- +------- +------- +------- +------- +------- + 


Figure 22: Dispatch for Interest Validations 


ValidationAlg: Optional ValidationAlgorithm TLV 
0000: An uncompressed ValidationAlgorithm TLV is included. 


0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is 
included. 


0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is 
included. Additionally, a SignatureTime TLV is inlined without a Type anda Length 
field. 


0011: AT_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm 
TLV is included. 


0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm 
TLV is included. Additionally, a SignatureTime TLV is inlined without a Type anda 
Length field. 


0101: Reserved. 
0110: Reserved. 
0111: Reserved. 
1000: Reserved. 
1001: Reserved. 
1010: Reserved. 
1011: Reserved. 
1100: Reserved. 
1101: Reserved. 
1110: Reserved. 
1111: Reserved. 


KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 
00: The KeyID TLV is absent. 


01: The KeyID TLV is present and uncompressed. 


10: AT_SHA-256 TLV is present, and the Type and Length fields are removed. The Length 
field is assumed to represent 32 bytes. The outer KeyID TLV is omitted. 
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11: AT_SHA-512 TLV is present, and the Type and Length fields are removed. The Length 
field is assumed to represent 64 bytes. The outer KeyID TLV is omitted. 


RSV: Reserved 
Must be set to 0. 


The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The Type field is 
omitted. 


6.3.3. Dispatch Extension 
The EXT_@ byte follows the description in Section 4.1.1 and is illustrated in Figure 23. 


(2] 1 2 3 4 5 6 7 

+---+---+---+---+---+---+---+---+ 
| NCS | RSV [EXT | 
+---+---+---+---+---+---+---+---+ 


Figure 23: EXT_0 Format 


NCS: Name Compression Strategy 
00: Names are compressed with the default name compression strategy (see Section 5.2). 


01: Reserved. 
10: Reserved. 
11: Reserved. 


RSV: Reserved 
Must be set to 0. 


EXT: Extension 
0: No extension byte follows. 


1: A further extension byte follows immediately. 


6.4. Content Objects 


6.4.1. Uncompressed Content Objects 


An uncompressed Content Object uses the base dispatch format (see Figure 4) and sets the C flag 
to @ and the P and M flags to 1 (Figure 24). The Content Object is handed to the CCNx stack without 
modifications. 
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2) 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
FATC eee e a a a 
+---+---+---+---+---+---+---+---+ 


Figure 24: Dispatch Format for Uncompressed CCNx Content Objects 


6.4.2. Compressed Content Objects 


The compressed Content Object uses the extended dispatch format (Figure 5) and sets the C, P, and 
M flags to 1. If a Content Object contains TLVs that are not mentioned in the following 
compression rules, then this message MUST be sent uncompressed. 


By default, the Content Object is compressed with the following base rule set: 


1. The version is elided from the fixed header and assumed to be 1. 
2. The PacketType field is elided from the fixed header. 


3. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the 
fixed header on decompression. 


The compressed CCNx LOWPAN Data message is visualized in Figure 25. 


T = Type, L = Length, V = Value 
Lc = Compressed Length, Vc = Compressed Value 


= optional field, | = mandatory field 
+----------------------------- + +------------------------- + 
| Uncompr. Fixed Header | | Compr. Fixed Header | 
+----------------------------- + +------------------------- + 
+--------- +--------- +--------- + +--------- + 

RCT RECTAL RCT V RCT Ve 
+--------- +--------- +------.-- + +--------- + 
: MSGH T : MSGH L : MSGH V MSGH Vc 
+--------- +--------- +--------- + +--------- + 
+--------- +--------- + +--------- + 
| MSGT T | MSGTL | | Name Vc | 
+--------- +--------- +--------- + +--------- + 
| Name T | Name L | Name V | ==> TEX PIINVC 
+--------- +--------- +--------- + +--------- +--------- + 
= PIYP T : PIPL <: PAAR WP : PAYL Lc PAYL V 
+--------- +--------- +--------- + +--------- +--------- + 

EXPT T EXPT EXPT V ~: VALG Lc VALG Vc 
+--------- +--------- +--------- + +--------- +--------- + 

PAYL T PAYL L PAYL V : VPAY Lc VPAY V 
+--------- +--------- +--------- + +--------- +--------- + 
: VALG T : VALGE LE == VALCOV = 
+--------- +--------- +--------- + 
: VPAY T VPAY L VPAY V :; 
+--------- +--------- +--------- + 


Figure 25: Compression of CCNx LOWPAN Data Message 


Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 26. 
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Q 1 
2) 1 2 3 4 5 6 7 8 9 2) 1 2 3 4 5 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 


| Ə | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT| 
+---+---+---+---+---+---+---+}---+---+---+---+---+---+---+---+---+ 


Figure 26: Dispatch Format for Compressed CCNx Content Objects 


FLG: Flags field in the fixed header 
See Section 6.3.2. 


FRS: Reserved field in the fixed header 
See Section 6.3.2. 


PAY: Optional Payload TLV 
See Section 6.3.2. 


RCT: Optional hop-by-hop Recommended Cache Time TLV 
0: The Recommended Cache Time TLV is absent. 


1: The Recommended Cache Time TLV is present, and the Type and Length fields are elided. 


MGH: Optional hop-by-hop MessageHash TLV 
See Section 6.4.2.1 for further details on the ordering of hop-by-hop TLVs. 


This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the 
Content Object MUST be sent uncompressed. 


0: The MessageHash TLV is absent. 


1: AT_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field 
is assumed to represent 32 bytes. The outer Message Hash TLV is omitted. 


PLTYP: Optional PayloadType TLV 
00: The PayloadType TLV is absent. 


01: The PayloadType TLV is absent, and TPAYLOADTYPE_DATA is assumed. 
10: The PayloadType TLV is absent, and T.PAYLOADTYPE_KEY is assumed. 
11: The PayloadType TLV is present and uncompressed. 


EXP: Optional ExpiryTime TLV 
0: The ExpiryTime TLV is absent. 


1: The ExpiryTime TLV is present, and the Type and Length fields are elided. 


VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 
See Section 6.3.2. 


RSV: Reserved 
Must be set to 0. 
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CID: Context Identifier 
See Figure 5. 


EXT: Extension 
0: No extension byte follows. 


1: Extension byte EXT_®@ follows immediately. See Section 6.4.3. 


6.4.2.1. Hop-By-Hop Header TLVs Compression 

Hop-by-hop header TLVs are unordered. For a Content Object message, two optional hop-by-hop 
header TLVs are defined in [RFC8609], but several more can be defined in higher-level 
specifications. For the compression specified in the previous section, the hop-by-hop TLVs are 
ordered as follows: 


1. Recommended Cache Time TLV 
2. Message Hash TLV 


Note: All hop-by-hop header TLVs other than the RecommendedCacheTime and MessageHash 
TLVs remain uncompressed in the encoded message, and they appear after the 
RecommendedCacheTime and MessageHash TLVs in the same order as in the original message. 


6.4.3. Dispatch Extension 
The EXT_@ byte follows the description in Section 4.1.1 and is illustrated in Figure 27. 


(2] 1 2 3 4 5 6 7 

+---+---+---+---+---+---+---+---+ 
| NCS | RSV [EXT | 
+---+---+---+---+---+---+---+---+ 


Figure 27: EXT_0 Format 


NCS: Name Compression Strategy 
00: Names are compressed with the default name compression strategy (see Section 5.2). 


01: Reserved. 
10: Reserved. 
11: Reserved. 


RSV: Reserved 
Must be set to 0. 


EXT: Extension 
0: No extension byte follows. 


1: A further extension byte follows immediately. 
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7. Compressed Time Encoding 


This document adopts the 8-bit compact time representation for relative time-values described in 
Section 5 of [RFC5497] with the constant factorC settoC := 1/32. 


Valid time offsets in CCNx and NDN range from a few milliseconds (e.g., lifetime of low-latency 
Interests) to several years (e.g., content freshness periods in caches). Therefore, this document 
adds two modifications to the compression algorithm. 


The first modification is the inclusion of a subnormal form [IEEE.754.2019] for time-codes with 
exponent 0 to provide an increased precision and a gradual underflow for the smallest numbers. 
The formula is changed as follows (a := mantissa, b := exponent): 


Subnormal (b ==0): (0+a/8)*2*C 
Normalized (b > 0): qd + a/8) * gb *C (see [RFC5497]) 
This configuration allows for the following ranges: 


e Minimum subnormal number: 0 seconds 

e 2nd minimum subnormal number: ~0.007812 seconds 
e Maximum subnormal number: ~0.054688 seconds 

e Minimum normalized number: ~0.062500 seconds 

e 2nd minimum normalized number: ~0.070312 seconds 
e Maximum normalized number: ~3.99 years 


The second modification only applies to uncompressible time offsets that are outside any security 
envelope. An invalid time-value MUST be set to the largest valid time-value that is smaller than 
the invalid input value before compression. 


8. Stateful Header Compression 


Stateful header compression in ICN LOWPAN enables packet size reductions in two ways. First, 
common information that is shared throughout the local LOWPAN may be memorized in the 
context state at all nodes and omitted from communication. Second, redundancy in a single 
Interest-Data exchange may be removed from ICN stateful forwarding on a hop-by-hop basis and 
memorized in en route state tables. 


8.1. LoWPAN-Local State 


A Context Identifier (CID) is a byte that refers to a particular conceptual context between 
network devices and MAY be used to replace frequently appearing information, such as name 
prefixes, suffixes, or meta information, suchas Interest lifetime. 
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Q 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
xI CID l 
+---+---+---+---+---+---+---+---+} 


Figure 28: Context Identifier 


The 7-bit CID is a locally scoped unique identifier that represents the context state shared between 
the sender and receiver of the corresponding frame (see Figure 28). If set, the most significant bit 
indicates the presence of another, subsequent CID byte (see Figure 33). 


The context state shared between senders and receivers is removed from the compressed packet 
prior to sending and reinserted after reception prior to passing to the upper stack. 


The actual information in a context and how it is encoded are out of scope of this document. The 
initial distribution and maintenance of shared context is out of scope of this document. Frames 
containing unknown or invalid CIDs MUST be silently discarded. 


8.2. En Route State 


In CCNx and NDN, Name TLVs are included in Interest messages, and they return in Data 
messages. Returning Name TLVs either equal the original Name TLV or contain the original Name 
TLV as a prefix. ICN LOWPAN reduces this redundancy in responses by replacing Name TLVs with 
single bytes that represent link-local HopIDs. HopIDs are carried as Context Identifiers (see 
Section 8.1) of link-local scope, as shown in Figure 29. 


3] 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
| 26 || HopID | 
+---+---+---+---+---+---+---+---+ 


Figure 29: Context Identifier as HopID 


A HopID is valid if not all ID bits are set to zero and invalid otherwise. This yields 127 distinct 
HopIDs. If this range (1...127) is exhausted, the messages MUST be sent without en route state 
compression until new HopIDs are available. An ICN LoWPAN node that forwards without 
replacing the Name TLV with a HopID (without en route compression) MUST invalidate the HopID 
by setting all ID bits to zero. 


While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to a 
Pending Interest Table (PIT) entry. Each HopID MUST be unique within the local PIT and only 
exists during the lifetime of a PIT entry. To maintain HopIDs, the local PIT is extended by two new 
columns: HIDi (inbound HopIDs) and HIDo (outbound HopIDs). 


HopIDs are included in Interests and stored on the next hop with the resulting PIT entry in the 
HIDi column. The HopID is replaced with a newly generated local HopID before the Interest is 
forwarded. This new HopID is stored in the HIDo column of the local PIT (see Figure 30). 
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PIT of B PIT Extension Pio C PIT Extension 
+-------- +------ ++------ +------ + +-------- +------ ++------ +------ + 
| Prefix | Face || HIDi | HIDO | | Prefix | Face || HIDi | HIDo | 
a he ee fl ft eS ee ee ae ee ee 
A a a hee E pO E AEA] 
+-------- +------ ++------ +------ + +-------- +------ ++------ +------ + 

A | A 
store | Tesi Ss SS SES ica SONE 
| send v | 
(om eae /pe, h_A EAR /pe, h_B Cn 8 
| BO) Sec eoee esas G aca ad E psec Soe ee >| C | 


Figure 30: Setting Compression State En Route (Interest) 


Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals 
the original Name TLV, then the name is entirely elided. Otherwise, only the matching name 
prefix is elided, and the distinct name suffix is included along with the HopID. When a response is 
forwarded, the contained HopID is extracted and used to match against the correct PIT entry by 
performing a lookup on the HIDo column. The HopID is then replaced with the corresponding 
HopID from the HIDi column prior to forwarding the response (Figure 31). 


PIT of B PIT Extension PIT of C PIT Extension 
+-------- +------ ++------ +------ + +-------- +------ ++------ +------ + 
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 
Se aL n eain E Ea S a S 
a l EA M a he si o aa i PA ier 
+-------- +------ ++------ +------ + +-------- +------ ++------ +------ + 

| $ | 
send | TSS SS Se SS See La~ send 
v match |v 
ee h_A e _B o 
A oe Seo aoe sa Meee | c | 


Figure 31: Eliding Name TLVs Using En Route State (Data) 


It should be noted that each forwarder of an Interest in an ICN LoWPAN network can individually 
decide whether to participate in en route compression or not. However, an ICN LOWPAN node 
SHOULD use en route compression whenever the stateful compression mechanism is activated. 


Note also that the extensions of the PIT data structure are required only at ICN LoWPAN nodes, 
while regular NDN/CCNx forwarders outside of an ICN LOWPAN domain do not need to implement 


these extensions. 


8.3. Integrating Stateful Header Compression 


ACID appears whenever the CID flag is set (see Figure 5). The CID is appended to the last ICN 
LoWPAN dispatch byte, as shown in Figure 32. 


Gündoğan, et al. Experimental Page 30 


RFC 9139 ICN Adaptation to LOWPANs November 2021 


...------- +-------- +------- ...------- +--...-+------- T 
ETT | Page | ICN LoWPAN Disp.| CIDs | Payload / 
------- +--------+------- -------+--...-+-------... 


Figure 32: LOWPAN Encapsulation with ICN LoWPAN and CIDs 


Multiple CIDs are chained together, with the most significant bit indicating the presence of a 
subsequent CID (Figure 33). This allows the use of multiple shared contexts in compressed 
messages. 


The HopID is always included as the very first CID. 


+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 
RCTI HopID | --> |1| CID --> |@| CID 
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 


Figure 33: Chaining of Context Identifiers 


9. ICN LOWPAN Constants and Variables 


This is a summary of all ICN LoWPAN constants and variables. 


DEFAULT_NDN_HOPLIMIT: 255 


10. Implementation Report and Guidance 


The ICN LoWPAN scheme defined in this document has been implemented as an extension of the 
NDN/CCNx software stack [CCN-LITE] in its IoT version on RIOT [RIOT]. An experimental 
evaluation for NDN over ICN LOWPAN with varying configurations has been performed in 
[ICNLOWPAN]. Energy profiling and processing time measurements indicate significant energy 
savings, and the amortized costs for processing show no penalties. 


10.1. Preferred Configuration 


The header compression performance depends on certain aspects and configurations. It works 
best for the following cases: 


e Signed time offsets compress, per Section 7, without the need for rounding. 


e The context state (e.g., prefixes) is distributed such that long names can be elided from 
Interest and Data messages. 


e Frequently used TLV type numbers for CCNx and NDN stay in the lower range (< 255). 


Name components are of type GenericNameComponent and are limited to a length of 15 bytes to 
enable compression for all messages. 
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10.2. Further Experimental Deployments 


An investigation of ICN LoWPAN in large-scale deployments with varying traffic patterns using 
larger samples of the different board types available remains as future work. This document will 
be revised to progress it to the Standards Track, once sufficient operational experience has been 
acquired. Experience reports are encouraged, particularly in the following areas: 


° The name compression scheme (Section 5.2) is optimized for short name components of type 
GenericNameComponent. An empirical study on name lengths in different deployments of 
selected use cases, suchas smart home, smart city, and industrial IoT can provide meaningful 
reports on necessary name component types and lengths. A conclusive outcome helps to 
understand whether and how extension mechanisms are needed (Section 5.3.3). Asa 
preliminary analysis, [ICNLOWPAN] investigates the effectiveness of the proposed 
compression scheme with URLs obtained from the WWW. Studies on deployments of 
Constrained Application Protocol (CoAP) [RFC7252] can offer additional insights on naming 
schemes in the IoT. 


° The fragmentation scheme (Section 4.2) inherited from 6LOWPAN allows for a transparent, 
hop-wise reassembly of CCNx or NDN packets. Fragment forwarding [RFC8930] with selective 
fragment recovery [RFC8931] can improve the end-to-end latency and reliability while it 
reduces buffer requirements on forwarders. Initial evaluations [SFR-ICNLOWPAN] show that 
a naive integration of these upcoming fragmentation features into ICN LoWPAN renders the 
hop-wise content replication inoperative, since Interest and Data messages are reassembled 
end-to-end. More deployment experiences are necessary to gauge the feasibility of different 
fragmentation schemes in ICN LoWPAN. 


e The context state (Section 8.1) holds information that is shared between a set of devices in a 
LoWPAN. Fixed name prefixes and suffixes are good candidates to be distributed to all nodes 
in order to elide them from request and response messages. More experience and a deeper 
inspection of currently available and upcoming protocol features is necessary to identify 
other protocol fields. 


e The distribution and synchronization of the context state can potentially be adopted from 
Section 7.2 of [RFC6775] but requires further evaluations. While 6LOWPAN uses the Neighbor 
Discovery protocol to disseminate state, CCNx and NDN deployments are missing out ona 
standard mechanism to bootstrap and manage configurations. 


e The stateful en route compression (Section 8.2) supports a limited number of 127 distinct 
HopIDs that can be simultaneously in use on a single node. Complex deployment scenarios 
that make use of multiple, concurrent requests can provide a better insight on the number of 
open requests stored in the PIT of memory-constrained devices. This number can serve as an 
upper bound and determines whether the HopID length needs to be resized to fit more 
HopIDs at the cost of additional header overhead. 


e Multiple implementations that generate and deploy the compression options of this memo in 
different ways will also add to the experience and understanding of the benefits and 
limitations of the proposed schemes. Different reports can help to illuminate the complexity 
of implementing ICN LoWPAN for constrained devices, as well as on maintaining 
interoperability with other implementations. 
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11. Security Considerations 


Main memory is typically a scarce resource of constrained networked devices. Fragmentation, 
as described in this memo, preserves fragments and purges them only after a packet is 
reassembled, which requires a buffering of all fragments. This scheme is able to handle fragments 
for distinctive packets simultaneously, which can lead to overflowing packet buffers that cannot 
hold all necessary fragments for packet reassembly. Implementers are thus urged to make use of 
appropriate buffer replacement strategies for fragments. Minimal fragment forwarding 
[RFC8930] can potentially prevent fragment buffer saturation in forwarders. 


The stateful header compression generates ephemeral HopIDs for incoming and outgoing 
Interests and consumes them on returning Data packets. Forged Interests can deplete the 
number of available HopIDs, thus leading to a denial of compression service for subsequent 
content requests. 


To further alleviate the problems caused by forged fragments or Interest initiations, proper 
protective mechanisms for accessing the link layer should be deployed. IEEE 802.15.4, e.g., provides 
capabilities to protect frames and restrict them to a point-to-point link or a group of devices. 


12. IANA Considerations 


12.1. Updates to the 6LOWPAN Dispatch Type Field Registry 


IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch Type Field" subregistry 
[RFC4944] [RFC8025] of the "IPv6 Low Power Personal Area Network Parameters" registry. Table 2 
represents the updates to the registry. 


Bit Pattern Page Header Type Reference 
00 000000 14 Uncompressed NDN Interest messages RFC 9139 
00 01xxxx 14 Compressed NDN Interest messages RFC 9139 
00 100000 14 Uncompressed NDN Data messages RFC 9139 
00 11xxxx 14 Compressed NDN Data messages RFC 9139 
01 000000 14 Uncompressed CCNx Interest messages RFC 9139 
01 01xxxx 14 Compressed CCNx Interest messages RFC 9139 


01 100000 14 Uncompressed CCNx Content Object messages RFC 9139 


01 11xxxx 14 Compressed CCNx Content Object messages RFC 9139 
Table 2: Dispatch Types for NDN and CCNx 
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Appendix A. Estimated Size Reduction 


In the following, a theoretical evaluation is given to estimate the gains of ICN LOWPAN compared 
to uncompressed CCNx and NDN messages. 


We assume that n is the number of name components; comps_n denotes the sum of n name 
component lengths. We also assume that the length of each name component is lower than 16 
bytes. The length of the content is given by clen. The lengths of TLV components are specific to 
the CCNx or NDN encoding and are outlined below. 
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A.1. NDN 


The NDN TLV encoding has variable-sized TLV fields. For simplicity, the 1-byte form of each TLV 
component is assumed. A typical TLV component therefore is of size 2 (Type field + Length field) + 
the actual value. 


A.1.1. Interest 


Figure 34 depicts the size requirements for a basic, uncompressed NDN Interest containing a 
CanBePrefix TLV, a MustBeFresh TLV, an InterestLifetime TLV set to 4seconds, and a HopLimit 
TLV set to 6. Numbers below represent the amount of bytes. 


Interest TLV = 2 
ee a ee i | 
Name | 22 ee | 
NameComponents = 2n + | 
| comps_n | 
al MMMM à = 21 + 2n + comps n 
CanBePrefix = 
MustBeFresh = 2 
Nonce = 6 | 
InterestLifetime = Z| l 
HopLimit =3 | 


Figure 34: Estimated Size ofan Uncompressed NDN Interest 


Figure 35 depicts the size requirements after compression. 


Dispatch Page Switch = 1 

NDN Interest Dispatch = 2 

Interest TLV = 1 

SCA click oie a a ae Ren aia las lee Se I | 

Name | | 

NameComponents = n/2 + = 10 + n/2 + comps_n 

| comps_n | 

SoS eooe coos SoS SSS SSCS ees f | 

Nonce = 4 | 

HopLimit = 1 | 

InterestLifetime = l 


Figure 35: Estimated Size ofa Compressed NDN Interest 
The size difference is 11 + 1.5n bytes. 


For the name /DE /HH/HAW/BT7, the total size gain is 17 bytes, which is 43% of the uncompressed 
packet. 
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A.1.2. Data 


Figure 36 depicts the size requirements for a basic, uncompressed NDN Data containing a 
FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is assumed, and the value is encoded 
using 1 byte. An HMACWithSha256 is assumed as a signature. The key locator is assumed to 
contain a Name TLV of length klen. 


Data TLV = 2 | 
ee ce eee F | 
Name eee | 
NameComponents = 2n + | 
| comps_n | 
SaaS aaa ae eee | 
SSeS e See eee eae eee , | 
MetaInfo l l 
FreshnessPeriod = 6 | 
| = 53 + 2n + comps_n + 
Fi iii i clen + klen 
Content = 2 + clen 


| 

| 

| 
SignaturelInfo l l 
SignatureType | | 
KeyLocator = 41 + klen | 
SignatureValue | | 
DigestSha256 | | 

| 


Figure 36: Estimated Size of an Uncompressed NDN Data 


Figure 37 depicts the size requirements for the compressed version of the above Data packet. 


Dispatch Page Switch 


| 
NDN Data Dispatch 2 | 
Sao ee ee eee ee ee ; | 
Name | | 

NameComponents = n/2 + 
| comps_n = 38 + n/2 + comps_n + 

See ee eee eee aaa = i | clen + klen 
Content =e eleni] 
KeyLocator = t klen | 
DigestSha256 = 92 | 
FreshnessPeriod = 1 


Figure 37: Estimated Size of a Compressed NDN Data 
The size difference is 15 + 1.5n bytes. 


For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes. 
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A.2. CCNx 

The CCNx TLV encoding defines a 2-byte encoding for Type and Length fields, summing up to 4 
bytes in total without a value. 

A.2.1. Interest 


Figure 38 depicts the size requirements for a basic, uncompressed CCNx Interest. No hop-by-hop 
TLVs are included, the protocol version is assumed to be 1, and the Reserved field is assumed to be 
0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects 
containing the specific key. 


Fixed Header = 8 | 

Message =4 | 

M ae OE r SU SLD AAA ri | 
Name | 4+ = 56 + 4n + comps_n 

NameSegments = 4n + 

| comps_n | 

SSeS ee ee SE u | 

KeyIdRestriction = 40 | 


Figure 38: Estimated Size of an Uncompressed CCNx Interest 


Figure 39 depicts the size requirements after compression. 


Dispatch Page Switch = 1 | 
CCNx Interest Dispatch = 2 | 
Fixed Header =—3 
ob pce a anata, ado SAGE nn Lee a Ss al J | 
Name | = 38 + n/2 + comps_n 
NameSegments = n/2 + 
| comps_n | 
ee E EE E . | 
T_SHA-256 = 32 l 


Figure 39: Estimated Size ofa Compressed CCNx Interest 
The size difference is 18 + 3.5n bytes. 


For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which is 53% of the uncompressed 
packet. 
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A.2.2. Content Object 


Figure 40 depicts the size requirements for a basic, uncompressed CCNx Content Object 
containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time, anda 

hash of the shared secret key. In the fixed header, the protocol version is assumed to be 1 and the 
Reserved field is assumed to be 0 


Fixed Header 
Message 


Name | 


ExpiryTime 
Payload 


ValidationAlgorithm | 
T_HMAC-256 = 

KeyID | 

SignatureTime | 


124 + 4n + comps_n + clen 


Figure 40: Estimated Size of an Uncompressed CCNx Content Object 


Figure 41 depicts the size requirements for a basic, compressed CCNx Data. 


Dispatch Page Switch 
CCNx Content Dispatch 
Fixed Header 


Name | 


ExpiryTime 
Payload 
T_HMAC-SHA256 
SignatureTime 
ValidationPayload 


, 


n/2 + 
comps_n 


| 
| 
| 
32 l 


89 + n/2 + comps_n + clen 


Figure 41: Estimated Size ofa Compressed CCNx Data Object 


The size difference is 35 + 3.5n bytes. 


November 2021 


For the name /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which is 40% of the uncompressed 
packet containing a 4-byte payload. 
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